Modus 


Integrating  Subjective  Trust  into 
Networked  Infrastructures 

Mark  D.  Heileman,  Ph.D.,  Modus  Operands  Inc. 
Gregory  L.  Heileman,  Ph.D.,  AHS  Engineering  Services 
Jong  S.  Hwang,  Air  Force  Research  Laboratory 
Prepared  for  SSTC  2009  -  22  April  2009 


SSTC  2009 


Slide  1  of  32 


Acknowledgements 


©  The  information  presented  is  the  result  of  work  on  a  Small  Business 
Innovation  Research  (SBIR)  Phase  I  project. 

©  This  work  was  funded  in  whole  or  in  part  by  Department  of  the  Air  Force 
Contract  FA8650-08-M-1441. 

©  The  Air  Force  Research  Laboratory's  Distributed  Collaborative  Sensor 

System  Technology  Branch  (AFRL/RYTC)  personnel  provided  guidance  and 
support  for  the  project. 


Modus 


SSTC  2009 


Slide  2  of  32 


Presentation  Agenda 


Objectives 


Requirements 


Demonstrations 


Recommendations 


Discussion 


©  What  we  were  trying  to  solve 
(Objectives). 

©  What  we  did  (Progress). 

©  What  the  results  were  (Requirements). 

©  How  we  did  it  (Demonstrations). 

©  What  we  learned  from  the  project 
( Recommendations) . 

©  Questions  and  comments  (Discussion). 
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0SD08-IA4:  Assuring  Trust  between  the  Edges 


Requirements  ^  Demonstrations  }  Recommendations  ^  Discussion 


Phase  I  Vision:  I  nvestigate  and  propose  an 

architecture  to  determine/ measure  and  convey 
the  trust  level  of  the  various  elements  in  a 
distributed  or  federated  network.  Provide 
architectural  and  design  documents  of  a  system 
concept  that  demonstrates  the  feasibility  of  the 
concept. 
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Phase  I  Research  Objectives 


Requirements  ^  Demonstrations  }  Recommendations  ^  Discussion 


1.  I  nvestigate  and  propose  an  architecture  for 
determining  and  conveying  trust  to  the  various 
elements  in  a  GIG-like  architecture,  (from  call) 

2.  Provide  architectural  and  design  documents  of  a 
system  that  demonstrate  feasibility,  (from  call) 

3.  Further  validate  our  approach  through  a 
prototype  that  exhibits  some  initial  functionality. 
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Progress  Review 


Objectives  ^  >  Requirements  >  Demonstrations  }  Recommendations 


Task  1:  Ontology  Creation 

Task  2:  Decision  Support 

Task  3:  HW/SW  Technologies  Support 

Task  4:  Trust  Services 

Task  5:  Prototype  Development 

Task  6:  Final  Technical  Report 
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Proposed  Solution 


Objectives  ^  Progress  j  ;  >  Demonstrations  }  Recommendations  ^  Discussion 


Green  Wave  -  an  open  architectural  framework  for 
determining  and  conveying  trust  to  the  various 
elements  in  a  GIG- like  network. 


Features: 

•  Flexible  distributed  architectural  framework  for 
experimenting  with  trust. 

•  Use  of  semantic  technologies  incorporated  into 
a  hybrid- based  trust  management  system. 
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Proposed  Solution 


Objectives 


Requirements 


3 


Demonstrations 


Recommendations 


Discussion 
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Architectural  Requirements  Review 


Objectives  ^  Progress  \  ■  >  Demonstrations  }  Recommendations  ^  Discussion 


©  Driving  requirement:  Reasoning  about  trust 
computationally  means  we  need  a  machine 
conveyabie  &  actionable  measure  for 
trust. 

©  This  implies:  A  (formal)  model  for  trust  (what 
computers  need). 

©  This  requires:  A  method  for  expressing  the  trust 
model  (a  policy  language). 

©  This  allows:  the  calculation  of  a  trust  measure. 

©  This  supports:  the  use  of  trust  in  decision 
making  (beyond  the  scope  of  this  proposal). 
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Architectural  Requirements  Review 


Objectives  ^  Progress  j  /  Demonstrations  ^  Recommendations  ^  Discussion 


Requirement  1.  Trust  Measure.  The  trust  measure 
must  be  quantifiable,  allowing  for  different  levels  of 
trust. 

©  Requirement  2.  Method  for  Expressing  and 
Calculating  Trust.  Trust  policies  must  be 
expressible  in  a  form  that  can  be  used  by  a  network 
entity  to  calculate  a  trust  measure. 

©  Requirement  3.  Use  of  Trust  in  Decision- 

Making.  Ultimately,  we  want  to  have  some  policy 
for  detailing  how  trust  measures  should  be  used  in 
decision-making. 

♦  Beyond  the  scope  of  the  current  research. 

♦  I  mportant  to  recognize  this  requirement,  as  it  provides 
the  motivation  for  the  calculation  of  trust  to  begin  with. 
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Architectural  Design  -  Trust  Model 


Objectives  ^  Progress  j  .■  >  Demonstrations  ^  Recommendations  ^  Discussion 


©  Trust  Sources  -  all  trust  in  a  system  emanates 
from  identifiable  trust  sources 

♦  certification  authorities 

♦  peer  assessments 

©  Dynamic  -  trust  evolves  over  time 

♦  as  new  information  is  obtained 

♦  as  resources  change  their  behavior 

©  Evidence- based  -  observable  actions  (or  lack 
thereof)  are  the  basis  for  direct  trust  measures 

©  Composable  -  ability  to  combine  trust 
measures  from  different  network  elements 
allows  for  indirect  trust  measures 
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Prototype  Demonstrations 


Objectives  ^  Progress  ^  Requirements  ^  >  Recommendations  ^  Discussion 


1.  Demonstration  of  how  semantic  technologies, 
trust  policies,  trust  calculations,  and  decision 
making  can  be  integrated  in  Trust  Evaluation 
Architecture 


2.  Demonstration  of  how  these  technologies  can 
be  implemented  in  a  next-generation 
networking  infrastructure. 
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Demonstration  Scenario 


Objectives  ^  Progress  ^  Requirements  ^  >  Recommendations  ^  Discussion 


Use  Case  5  (from  kickoff  briefing):  Proximate 

sensors  in  a  sensor  network  are  providing  disparate 
information.  Which  sensors  do  you  believe?  A 
functioning  sensor  can  provide  spurious  values. 

Are  there  really  chemical  weapons  on  the 
battlefield?  More  importantly,  can  we  account  for 
the  trust  (and  provenance)  of  information  within 
the  decision-making  framework?  Can  we  show  that 
a  "downstream"  decision  relies  on  a  few  facts  that 
have  low  trust? 

Elaboration  of  Use  Case  5  -  Perimeter  monitoring 
system  with  two  sensor  networks  using  semantic 
technology  in  trust  management. 
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Use  Case  5  -  UML 


Objectives 


Requirements 


5ensor  mB 


Demonstrations 

Network  Subsystem 


Recommendations 


Discussion 


Sensor  Network  A 


Trust  Calculation  A 


Network  Manager  A 


Sensor  Network  B 


Trust  Calculati 


Jor^B^V 


Network  Manager  B 


Network  Manager  C 


Trust  Calculati 
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Use  Case  5:  Sensor  Networks 


Objectives 


Requirements 


Demonstrations 


Recommendations 


Discussion 


Sensor  Network  Sensor  Network 
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Semantic  Technology  &  Trust 


Objectives 


Requirements 


Demonstrations 


Recommendations 


Discussion 


Harmonization 


Chemical  Sensor  Motion  Sensor 

©  Sensor 
©  Capability 
♦  Event  Capture 

■  Chemical  Detection 

©  Sensor 
©  Capability 
♦  Event  Capture 

■  Motion  Detection 

Common 

Vocabulary 
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Semantic  Technology  &  Trust 


Objectives 


Requirements 


Demonstrations 


Recommendations 


Discussion 


Semantic  Assistance  in  Policies 
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Use  Case  5:  Activity  Diagram 


Objectives 


Requirements 


Demonstrations 


Recommendations 


Discussion 


Activity 


Sensor  rrisses  event  Environmental  event  occur ed 


) 


Sensor  notices  event 


Establishing  reputation  based  on  environmental  events  as  a  catalyst. 


Iterate  Sensors 


End  of  Sensor  list 


Next  sensor  exists 


Check  capability  of  next  sensor 


o 


No  matching  capability 


Similar  capability 


Query  sensor  about  event 


Dissimilar  events 


^Decrease  reputation^ 


Similar  events 


G 


Increase  reputation 


:i  o  n 
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Demonstration  1 


Objectives  ^  Progress  ^  Requirements  ^  >  Recommendations  ^  Discussion 


©  Fuel  Depot  at  Cape  Canaveral  AFS 

♦  Sensor  Network  A  -  chemical  sensors 

♦  Sensor  Network  B  -  satellite  data 

©  Front-end  involves  integration  with  geospatial 
data  to  incorporate  proximity  into  trust  policies. 

©  Makes  use  of  Web  I  nformation  Quality 

Assessment  (WIQA)  Framework  for  the  policy 
language. 

©  Represents  the  trust  ontology  using  the  TriG 
syntax. 
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Demonstration  2 


Objectives  ^  Progress  ^  Requirements  ^  >  Recommendations  ^  Discussion 


Based  on  the  Transient  Network  Architecture: 

©  Persistent  I  dentification 

♦  Global  Uniqueness 

♦  Certification  and  Name  Resolution 

■  Instance  (red).  Local  (yellow).  Global  (green) 

■  Green  implies  yellow  implies  red 

©  Distributed  Control-Plan  Functionality 

♦  Supports  unstructured  networks 

♦  Persistent  I  dentifier  ( PI ) 

■  Holds  information  associated  with  each  network  entity 

♦  Control- Plane  Provisioning 

■  Uses  the  ghost/shell  model 
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Transient  Network  Architecture 


Objectives 


Requirements 


Demonstrations 


Recommendations 


Discussion 


/  Aol  [sate  1 1  its] 
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Aol  [sensor]  \ 
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lensor 
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Base  £  tation 


PI2/oall2 


PI3/jserl 


PI  :  Persistent  Identifier 


Aol ;  Area  of  Influence 
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Transient  Network  Architecture 


Objectives 


Requirements 


Demonstrations 


Recommendations 


Discussion 


AOI:  Area  of  Influence 

©  Three  levels  of  resolution  and  certification 

•  I  nstance  or  Red:  Ghost 

•  Local  or  Yellow:  Aol 

•  Global  or  Green:  Green  Networks 
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Transient  Network  Architecture 


Objectives  ^  Progress  ^  Requirements  ^  >  Recommendations  ^  Discussion 


©  Complete  network  layer,  replacing  I P. 

©  Routing  based  on  Pis. 

©  Entities  interact  with  Persistent  Identifier 
Networking  Layer  (PINL)  via  a  Neutral 
Environment  Language  for  Operation  (NELO). 

©  Provided  I  nterfaces: 

♦  PI  LOW  -  routing  component. 

♦  Agent  Service  -  general  ghost  service. 

♦  Discovery  Module  -  allows  entities  to  discover  one 
another. 

♦  Routing  Module  -  accepts  packets  from  PI  LOW,  and 
routes  based  on  PI . 
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PI  NETWORK  |  LINK  LAYER 
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Recommendations 


Discussion 
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PINL  Layer 


Objectives 


Requirements 
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Demonstrations 
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Recommendations 
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Demonstration  2 


Objectives 


Requirements 


Demonstrations 


Recommendations 


Discussion 
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Use  Cases 


Objectives  ^  Progress  ^  Requirements  ^  >  Recommendations  ^  Discussion 


Use  Case  4  (from  kickoff  briefing):  An  enemy  is  able 
to  compromise  network  elements  in  order  to  inject 
spurious  information.  We  do  not  want  to  allow  the 
enemy  to  "escalate"  an  attack,  but  we  are  not  sure 
if  it  really  is  an  attack?  Typically,  if  a  network 
element  is  "suspect",  it  is  excluded  from  the 
network,  even  though  it  may  still  possess  some 
informational  value.  E.g.,  an  enemy  has  corrupted 
a  machine's  database,  but  the  Gl  S  unit  on  the 
machine  is  still  sending  information  that  can  be 
validated  via  message  digests. 

Elaboration  of  Use  Case  4  -  hw  dongle  used  in 
out-of-band  communication,  and  incorporated  into 
trust  calculations. 
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Use  Case  4:  Enemy  Compromise 


Objectives 


Requirements 


Demonstrations 


Recommendations 


Discussion 
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Recommendations 


Objectives  >  Progress  >  Requirements  >  Demonstrations  Discussion 


©  We  view  the  Phase  I  work  as  one  cycle  through 
an  iterative  and  incremental  development 
process  (spiral  model)  aimed  at  creating  a  Trust 
Evaluation  Architecture. 

©  Iteration  1: 

♦  Elidt  initial  requirements. 

♦  Design  a  preliminary  architecture. 

♦  Prototype  pieces  of  the  architecture  to  validate  ideas. 

©  Iteration  2..n: 

♦  Continue  to  iteratively  develop  the  Trust  Evaluation 
Architecture,  building  upon  the  previous  iterations. 

♦  Allows  for  extensive  feedback/input  from  project 
sponsors. 
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Specific  Recommendations 


Objectives  ^  Progress  ^  Requirements  ^  Demonstrations  j  Discussion 


1.  Fully  develop  formal  model  for  trust.  A  fully  specified  formal 
model  for  trust  allows  for: 

♦  Determination  of  limits  of  what  the  Trust  Evaluation  Architecture. 

♦  Proofs  for  the  correctness  of  its  operation  under  various  threat  models. 

2.  Create  a  complete  trust  policy  specification  language  on  top  of  the 
formal  model,  along  with  query  capabilities  with  respect  to  these 
trust  policies: 

♦  I  ntegrate  previous  trust  research. 

♦  Allow  a  decision-maker  to  specify  arbitrarily  complex  policies,  and  to 
reason  over  these  policies. 

♦  The  use  of  semantic  technologies  within  this  reasoning  framework  should 
also  be  more  fully  explored. 

3.  Develop  a  communications  framework  that  allows  trust 
calculations  to  be  integrated  at  various  levels  within  a 
communications  protocol  stack,  and  within  sensor  networking 
environments  (sandbox). 

♦  I  nitial  work  demonstrated  how  trust  calculations  can  be  integrated  into  an 
experimental  communications  substrate. 

♦  The  Trust  Evaluation  Architecture  must  leverage  state-of-the-art  advances 
in  security  and  networking. 
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Discussion 


Objectives  ^  Trust  Research  ^  Requirements  ^  Preliminary  Design  ^  Case  Studies 


Discussion 


► 
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Acronyms  and  Terms 


Aol 

Ghost 

GIG 

NELO 

PI 

PI  LOW 
PI  NL 
SBIR 
TNA 
WIQA 


Area  of  I  nterest 

Generic  host 

Global  I  nformation  Grid 

Neutral  Environment  Language  for  Operation 

Persistent  I  dentifier 

Persistent  I  dentifier  Tables 

Persistent  Identifier  Networking  Layer 

Small  Business  Innovation  Research 

Transient  Network  Architecture 

Web  I  nformation  Quality  Assessment  Framework 
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